The objectives of the Preliminary phase are:

• To review the organizational context for conducting enterprise architecture
• To identify the sponsor stakeholder(s) and other major stakeholders impacted by the business directive to create an enterprise architecture and determine their requirements and priorities from the enterprise, their relationships with the enterprise, and required working behaviors with each other
• To ensure that everyone who will be involved in, or benefit from, this approach is committed to the success of the architectural process
• To enable the architecture sponsor to create requirements for work across the affected business areas
• To identify and scope the elements of the enterprise organizations affected by the business directive and define the constraints and assumptions (particularly in a federated architecture environment)
• To define the "architecture footprint" for the organization - the people responsible for performing architecture work, where they are located, and their responsibilities
• To define the framework and detailed methodologies that are going to be used to develop enterprise architectures in the organization concerned (typically, an adaptation of the generic ADM)
• To confirm a governance and support framework that will provide business process and resources for architecture governance through the ADM cycle; these will confirm the fitness-for-purpose of the Target Architecture and measure its ongoing effectiveness (normally includes a pilot project)
• To select and implement supporting tools and other infrastructure to support the architecture activity
• To define the architecture principles that will form part of the constraints on any architecture work

Approach

This Preliminary phase is about defining "where, what, why, who, and how we do architecture" in the enterprise concerned. The main aspects are as follows:

• Defining the enterprise
• Identifying key drivers and elements in the organizational context
• Defining the requirements for architecture work
• Defining the architecture principles that will inform any architecture work
• Defining the framework to be used
• Defining the relationships between management frameworks
• Evaluating the enterprise architecture maturity

The enterprise architecture provides a strategic, top-down view of an organization to enable executives, planners, architects, and engineers to coherently co-ordinate, integrate, and conduct their activities. The enterprise architecture framework provides the strategic context for this team to operate within.

The term enterprise architecture was first coined by John Zachman as a means of creating a coherent way of modeling an enterprise to enable the efficient and effective deployment of IT. It leveraged concepts from other management and engineering frameworks making it easier to integrate enterprise architecture into the overall corporate culture and governance.

Therefore, developing the enterprise architecture is not a solitary activity and the enterprise architects need to recognize the interoperability between their frameworks and the rest of the business.

Strategic, interim, and tactical business objectives and aspirations need to be met. Similarly, the enterprise architecture needs to reflect this requirement and allow for operation of architecture discipline at different levels within the organization.

Depending on the scale of the enterprise and the level of budgetary commitment to enterprise architecture discipline, a number of approaches may be adopted to sub-divide or partition architecture teams, processes, and deliverables. Approaches for architecture partitioning are discussed in Part V, Architecture Partitioning . The Preliminary phase should be used to determine the desired approach to partitioning and to establish the groundwork for the selected approach to be put into practice.

When using an iterative process for architecture development, the activities within the Preliminary phase may be revisited a number of times, alongside related activities within the Architecture Vision phase, in order to ensure that the tailored framework is suitable to address a specific architecture problem.

Enterprise

One of the main challenges of enterprise architecture is that of enterprise scope. In many organizations enterprise architecture is part of the Chief Information Officer (CIO) responsibilities and accountabilities and is considered a strategic planning asset that is becoming increasingly an integral part of business management.

In other organizations, enterprise architecture has an even broader remit and more generally supports the management of strategic change across all aspects of the enterprise. In either case, the strategic perspective that enterprise architecture can bring is required from the outset.

Therefore, the scope will determine those stakeholders who will derive most benefit from the new or enhanced enterprise architecture. It is imperative that a sponsor is appointed at this stage to ensure that the resultant activity has resources to proceed and the clear support of the business management. The enterprise may encompass many organizations and the duties of the sponsors are to ensure that all stakeholders are included in some part in the resultant architecture work, definitions, and work products.

Organizational Context

In order to make effective and informed decisions about the framework for architecture to be used within a particular enterprise, it is necessary to understand the context surrounding the architecture framework. Specific areas to consider would include:

• The commercial models for enterprise architecture and budgetary plans for enterprise architecture activity. Where no such plans exist, the Preliminary phase should be used to develop a budget plan.
• The stakeholders for architecture in the enterprise; their key issues and concerns.
• The intentions and culture of the organization, as captured within board business directives, business imperatives, business strategies, business principles, business goals, and business drivers.
• Current processes that support execution of change and operation of IT, including the structure of the process and also the level of rigor and formality applied within the organization. Areas for focus should include:
  • Current methods for architecture description
  • Current project management frameworks and methods
  • Current systems management frameworks and methods
  • Current project portfolio management processes and methods
  • Current application portfolio management processes and methods
  • Current technology portfolio management processes and methods
  • Current information portfolio management processes and methods
  • Current systems design and development frameworks and methods
• The Baseline Architecture landscape, including the state of the enterprise and also how the landscape is currently represented in documentation form.
• The skills and capabilities of the enterprise and specific organizations that will be adopting the framework.

Review of the organizational context should provide valuable requirements on how to tailor the architecture framework in terms of:

• Level of formality and rigor to be applied
• Level of sophistication and expenditure required
• Touch-points with other organizations, processes, roles, and responsibilities
• Focus of content coverage

Requirements for Architecture Work

The business imperatives behind the enterprise architecture work drive the requirements and performance metrics for the architecture work. They should be sufficiently clear so that this phase may scope the business outcomes and resource requirements, and define the outline enterprise business information requirements and associated strategies of the enterprise architecture work to be done. For example, these may include:

• Business requirements
• Cultural aspirations
• Organization intents
• Strategic intent
• Forecast financial requirements

Just one or a combination of these need to be articulated so that the sponsor can identify all the key decision-makers and stakeholders involved and generate a Request for Architecture Work.

Principles

The Preliminary phase defines the architecture principles that will form part of the constraints on any architecture work undertaken in the enterprise. The issues involved in this are explained in Part III, Architecture Principles .

The definition of architecture principles is fundamental to the development of an enterprise architecture. Architecture work is informed by business principles as well as architecture principles. The architecture principles themselves are also normally based in part on business principles. Defining business principles normally lies outside the scope of the architecture function. However, depending on how such principles are defined and promulgated within the enterprise, it may be possible for the set of architecture principles to also restate, or cross-refer to a set of business principles, business goals, and strategic business drivers defined elsewhere within the enterprise. Within an architecture project, the architect will normally need to ensure that the definitions of these business principles, goals, and strategic drivers are current, and to clarify any areas of ambiguity.

The issue of architecture governance is closely linked to that of architecture principles. The body responsible for governance will also normally be responsible for approving the architecture principles, and for resolving architecture issues. This will normally be one of the principles cited. The issues involved in governance are explained in Part VII, Architecture Governance .

Management Frameworks

The TOGAF Architecture Development Method (ADM) is a generic method, intended to be used by enterprises in a wide variety of industry types and geographies. It is also designed for use with a wide variety of other enterprise architecture frameworks, if required (although it can be used perfectly well in its own right, without adaptation).

TOGAF has to co-exist with and enhance the operational capabilities of other management frameworks that are present within any organization either formally or informally. In addition to these frameworks, most organizations have a method for the development of solutions, most of which have an IT component. The significance of systems is that it brings together the various domains (also known as People, Processes, and Material/Technology) to deliver a business capability.

The main frameworks suggested to be co-ordinated with TOGAF are:

• Business Capability Management (Business Direction and Planning) that determines what business capabilities are required to deliver business value including the definition of return on investment and the requisite control/performance measures.
• Portfolio/Project Management Methods that determine how a company manages its change initiatives.
• Operations Management Methods that describe how a company runs its day-to-day operations, including IT.
• Solution Development Methods that formalize the way that business systems are delivered in accordance with the structures developed in the IT architecture.

As illustrated in Management Frameworks to Co-ordinate with TOGAF , these frameworks are not discrete and there are significant overlaps between them and the Business Capability Management. The latter includes the delivery of performance measured business value.

The overall significance is that the enterprise architect applying TOGAF cannot narrowly focus on the IT implementation, but must be aware of the impact that the architecture has on the entire enterprise.

 

The Preliminary phase therefore involves doing any necessary work to adapt the ADM to define an organization-specific framework, using either the TOGAF deliverables or the deliverables of another framework. The issues involved in this are discussed in Adapting the ADM .

Relating the Management Frameworks

Interoperability and Relationships between Management Frameworks illustrates a more detailed set of dependencies between the various frameworks and business planning activity that incorporates the enterprise's strategic plan and direction. The enterprise architecture can be used to provide a structure for all of the corporate initiatives, the Portfolio Management Framework can be used to deliver the components of the architecture, and the Operations Management Framework supports incorporation of these new components within the corporate infrastructure.

The business planners are present throughout the process and are in a position to support and enforce the architecture by retaining approval for resources at the various stages of planning and development.

The solution development methodology is used within the Portfolio Management Framework to plan, create, and deliver the architectural components specified in the portfolio and project charters. These deliverables include, but are not exclusively, IT; for example, a new building, a new set of skills, production equipment, hiring, marketing, and so on. Enterprise architecture potentially provides the context for all enterprise activities.

The management frameworks are required to complement each other and work in close harmony for the good of the enterprise.

Business planning at the strategy level provides the initial direction to enterprise architecture. Updates at the annual planning level provide a finer level of ongoing guidance. Capability-based Planning is one of many popular techniques for business planning.

Enterprise architecture structures the business planning into an integrated framework that regards the enterprise as a system or system of systems. This integrated approach will validate the business plan and can provide valuable feedback to the corporate planners. In some organizations, the enterprise architects have been moved to or work very closely with the strategic direction groups. TOGAF delivers a framework for enterprise architecture.

Portfolio/project management is the delivery framework that receives the structured, detailed direction that enables them to plan and build what is required, knowing that each assigned deliverable will be in context (i.e., the piece of the puzzle that they deliver will fit into the corporate puzzle that is the enterprise architecture). Often this framework is based upon the Project Management Institute or UK Office of Government Commerce (PRINCE2) project management methodologies. Project architectures and detailed out-of-context design are often based upon systems design methodologies.

Operations management receives the deliverables and then integrates and sustains them within the corporate infrastructure. Often the IT service management services are based upon ISO 20000 or BS15000 (ITIL).

Planning for Enterprise Architecture/Business Change Maturity Evaluation

Capability Maturity Models (CMMs - detailed in Part VII, Architecture Maturity Models) are useful ways of assessing selected factors. Once the factors have been determined, it is preferable that the capability models be customized for each factor and then used in workshops as a guide for evaluating how to best develop and implement the architecture. These workshops could serve as an excellent way of enlisting major stakeholder support within the organization.

The actual levels of maturity provide a strategic measure of the organization's ability to change, as well as a series of sequential steps to improve that ability. It is mainly a business as well as a technical assessment and gives executives (line of business as well as IT) an insight into how to pragmatically move forward.

It is important that the workshops include a representation from all of the stakeholders identified in the Preliminary phase and later.

A good enterprise architecture maturity model covers a wide range of enterprise characteristics, both business and technical, many of which can already be determined through an analysis of the derived Target Architecture. Organizations can determine their own factors and derive the appropriate maturity models, but it is recommended to take an existing "open" model and customize it if only to avoid delays inherent in getting organizational agreement on the factors and maturity models.

A good example of such a model is the NASCIO Enterprise Architecture Maturity Model¹ which has adopted the following criteria:

• Administration: Governance roles and responsibilities.
• Planning: Enterprise Architecture program roadmap and Implementation Plan.
• Framework: Processes and templates used for enterprise architecture.
• Blueprint: Collection of the actual standards and specifications.
• Communication: Education and distribution of enterprise architecture and blueprint detail.
• Compliance: Adherence to published standards, processes, and other enterprise architecture elements, and the processes to document and track variances from those standards.
• Integration: Touch-points of management processes to the enterprise architecture.
• Involvement: Support of the enterprise architecture program throughout the organization.

Other examples include the US Federal Enterprise Architecture Maturity Model. Even though the models are originally from government, they are equally applicable to industry.